It is said that a client device (also known as “user equipment”) “belongs” to the network of a given operator when the user of the client device possesses an account with that operator, and this applies regardless of which access network is actually used by the client device for connecting to the network of the operator. By way of example, such a client device may be a fixed or mobile terminal, or a residential gateway, or it may be a gateway in a business, or indeed a voice gateway of a network operator such as a digital subscriber line access multiplexer using session initiation protocol (DSLAM-SIP); i.e. a device that collects digital subscriber line (DSL) data traffic passing via some number of telephone lines.
Conventional advanced session control protocols such as SIP use so-called “signaling” messages, which are messages enabling a terminal to request a connection with another terminal, or indeed messages indicating that a telephone line is busy, or indicating that some particular telephone is connected to the network and can be reached in such and such a manner.
The SIP was defined by the Internet engineering task force (IETF) in Document RFC 3261. This protocol makes it possible to set up, modify, and terminate multimedia sessions in a network using IP. SIP has subsequently been extended, in particular in Document RFC 3265. This extension serves to make event notification procedures possible.
SIP is used in particular in infrastructures of the IP multimedia system (IMS) type. IMS was defined by the standards Organizations Third generation partnership project (3GPP) and Telecommunications and Internet converged services and protocols for advancing networking (TISPAN). It is a network architecture that was introduced by 3GPP for mobile networks that has subsequently been taken on by TISPAN for fixed networks. This architecture enables multimedia sessions to be set up dynamically and controlled between two clients, and also enables resources to be reserved in the network transporting the multimedia streams. By means of this architecture, network operators can conveniently implement a management policy, can provide a predetermined level of quality of service (QoS), and can calculate how much to bill clients. At present, IMS gives access to services of the telephone, videophone, presence, and instant messaging types, and it also manages interaction between them.
When a user seeks to benefit from services made available by an IMS network, the user sends signaling messages to the network that may include in particular various types of request.
Firstly, a user's client device needs to register with the network (apart from certain exceptions such as some emergency calls). When the network is incapable of linking the registration with an earlier registration (e.g. as a result of a network breakdown, or after the terminal has been switched off for a duration longer than a predetermined value), the registration is considered as being an initial registration. After an initial registration, the user's client device must periodically send a request to the network in order to confirm that it seeks to maintain its registration; the registration is maintained only for a predetermined duration that is referred to herein as the “registration refresh period” (often labeled “Expires” in the technical literature); by way of example, above-mentioned Document RFC 3261 recommends a registration refresh period equal to 3600 seconds. In practice, it is the network that informs each registering client device of the value of the registration refresh period with which the client device needs to comply in order to benefit from the services made available by the network without interruption.
Thus, in order to be able to register client devices, IMS networks have one or more registration servers referred to as serving-call server control function (S-CSCF) servers that are suitable (among other functions) for managing the procedure of registering devices connected to the network.
In addition, these networks also have one or more servers known as “interrogating-call server control function” (I-ICSF) servers, which indeed are often physically combined with servers of the S-CSCF type in order to constitute servers referred to as I/S-CSCF servers, that at the time a client device registers interrogate a home subscriber server (HSS) in order to be able to select all S-CSCF server that possesses the characteristics that are necessarily required (and also where appropriate optionally required) for reaching the level of service to which the user has subscribed. Each HSS has a client database and is thus the equivalent in an IP network of a home location register (HLR) as used in networks of the global system for mobile communications (GSM) type. Each HSS contains the “profile” of some number of client devices of the network, which profile includes the registration states, authentication and location data, and the subscribed services of each client device.
After an S-CSCF server has been allocated to a user, each user can send a request to subscribe to certain services, with the subscription being valid for the current connection. The general principle is that a client device can subscribe to some particular technical service by using an appropriate request (SIP SUBSCRIBE). Thus, in the event of making a subscription to the state of a resource, event notifications (SIP NOTIFY) are sent to the client device whenever the state of the resource changes; for example, when the user of a terminal has a voice mailbox on the network, the terminal may subscribe to a message notification service, i.e. the terminal may request to be informed each time a message is recorded in the voice mailbox; likewise the user's terminal may request to be notified about its own registration state, and so on.
Initial subscription requests are sent either automatically immediately after the terminal is switched on or after an application installed on the terminal is started, or else following a user action on the interface of the terminal. For each subscription, the client device must begin by sending an initial request, and then periodically it must send a request for renewing the subscription (the subscription is said to be “refreshed”).
For each subscription (whether an initial subscription or refreshing a subscription), the network informs the client device of the refresh period desired by the operator of the network for that subscription. According to Document RFC 3265, the maximum refresh period associated with a subscription to a particular service (or “event-package”) made available by the network is defined by referring to the document that defines that particular technical service; for example, for the subscription to notification of new messages, Document RFC 3842 recommends a refresh period lying in the range a few hours to a few days (cf. “event-package message summary”).
The subscription refresh period may be different for each type of subscribed service, and, a priori, it is also independent from the registration refresh period.
In this context, during normal operation of an SIP network, the network receives initial registration requests and initial subscription requests together with refresh requests for registration and for subscriptions, progressively as the users of the network connect thereto, initialize, and then renew their registrations and their subscriptions at the ends of the respective refresh periods provided for that purpose. Naturally, each IP network operator must make provision for sufficient processing capacity in the nodes of the network to be able to handle the corresponding frequency of requests, in particular as a function of the usual number of users of the network.
Selecting a value for the refresh period is a strategic decision, since this value determines the dimensioning of the equipment in the core network: if the refresh period is too short, then the extra cost in terms of dimensioning is high; if it is too long, then information about the presence of such and such a client device in the network is not very reliable.
Certain manufacturers provide for the possibility of adjusting the refresh period as a function of the technology of the access type (ADSL, xDSL, WiFi, WiMAX, GSM, LTE, and so on) used by the client device. Nevertheless, for any given type of access, there remains the question as to whether or not it is possible, still for the purpose of reducing as much as possible costs relating to registration and/or subscription traffic, to further refine the value(s) of one or more refresh periods as a function of other practical criteria.